The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In distributed computer networks, authenticating users of costly, complex software-as-a-service (SaaS) systems is subject to well-known security issues relating to managing the online identities of users and providing effective corporate access to application systems. Single sign-on (SSO), using the security assertion markup language (SAML), is a solution to such issues in some contexts. An identity provider (IdP) computer typically authenticates an enterprise user using form-based authentication. The IdP computer sends a SAML assertion to a web service provider with attribute data about an authenticated subject, who typically is a user seeking access to a SaaS system. In many cases the subject in question has already authenticated to a personal computer or smartphone, for example, by logging in with a username and password to an app or application on a client computer or smartphone, and that device has also authenticated to a network according to a network security protocol. It would be useful to accomplish SaaS authentication without requiring the user to enter credentials a second time. There are attempts to address these issues, but they fail to do so in a secure manner with end-to-end security for all communication.
One solution involves a network access device (NAD), such as a router or switch, attaching a session identifier to a message in transit from a client to an IdP. That solution may give false confidence that the session identifier is not exposed to capture or spoofing, because the solution is based on a hypertext transfer protocol (HTTP) session that can be captured, spoofed, or succumb to other attacks such as a man-in-the-middle (MitM). Simply stated, HTTP should not be used to transport a secret across an insecure network. The problem is exacerbated when an IdP resides beyond a local network, such as in a shared datacenter or cloud computing facility. The insecurity of HTTP cannot be fixed by merely changing the communication to HTTP secure (HTTPS), because that would require a NAD to intercept and alter a message between a client and an IdP, which in itself is a MitM attack that could disturb a user experience by triggering a certificate warning or a connection refusal.
Thus, there has been no secure and seamless way to transport a session identifier between a client, a NAD, and an IdP during an SSO flow between the client and a web service provider. Lacking end-to-end security, attempted solutions fail to protect against eavesdropping or modification of a session identifier early in the SSO flow. A way is needed that provides a seamless user experience and allows for secure distribution of a session identifier between a client, a NAD, and an IdP.